Well, no need to, I guess. I doubt there'll be that many people interested in TS2 support...
OK, here's a TS3 support development report. It seems the best way to get information from a TS3 server is to connect to its Query port and then use special commands and parse results. There is a nice managed library simplifying all this. I was able to connect to a TS3 server and see what channels are there and who is connected. But then problems appeared. As I see it there are no notifications available that would fire when someone starts/stops to talk. The idea was to use regular polling, say every 2 seconds, and see if there is someone talking. But not only this creates unnecessary and not quite negligible traffic, but more importantly there seems to be no indication of currently talking users either. I'm in contact with the library author, waiting for further ideas... Do you have any? 
My view is you can apply limitations and restrictions only when usage is on the rise. Limiting demo now would have disastrous consequences. LFS stands on two legs, demo and licence. By removing BL1R and especially BL2R it shot itself into one leg, and never fully recovered. By applying 60 minutes online gaming or something even more restrictive, it would cut that leg completely... and die of the consequences a few months later.
My view is that in fact it needs to recover, it needs to get more meat, to heal. And that could be (maybe) achieved not by restricting demo, but by allowing more content there. The obvious change is allowing reversed Blackwood tracks again. Demo accounts could be time-limited, but it should be at least 3 months, preferably 6, and this only so that the LFSW database is under control. I would consider even adding one more powerful car to Demo, maybe RB4 or even FXR, but I know some people would be outraged by that, so I'm not proposing it.
I see one interesting problem concerning demo racing. More and more people get specialized - they do only one combo, indefinitely, thousands, even tens of thousands of laps. They are not interested in doing anything else. They do cool lap times on BL1+FBM or BL1+XFG or BL1+XGR or BL2+XFG or BL2+XRG and they are not really interested in trying anything new. They will never buy S2, because instead of gods they'll be newbies again. By opening BL1R and BL2R tracks I would also hope to change this approach, to break this specialization.
My view is that in fact it needs to recover, it needs to get more meat, to heal. And that could be (maybe) achieved not by restricting demo, but by allowing more content there. The obvious change is allowing reversed Blackwood tracks again. Demo accounts could be time-limited, but it should be at least 3 months, preferably 6, and this only so that the LFSW database is under control. I would consider even adding one more powerful car to Demo, maybe RB4 or even FXR, but I know some people would be outraged by that, so I'm not proposing it.
I see one interesting problem concerning demo racing. More and more people get specialized - they do only one combo, indefinitely, thousands, even tens of thousands of laps. They are not interested in doing anything else. They do cool lap times on BL1+FBM or BL1+XFG or BL1+XGR or BL2+XFG or BL2+XRG and they are not really interested in trying anything new. They will never buy S2, because instead of gods they'll be newbies again. By opening BL1R and BL2R tracks I would also hope to change this approach, to break this specialization.
Fatal, if you think you know about a bug, it is maybe best to post it here.
Okram, I'm not sure how this could work. Where would the PHP request be sent? To LFS server, using InSim connection? No such framework is implemented now and I do not see an easy and obvious way to implement one.
Okram, I'm not sure how this could work. Where would the PHP request be sent? To LFS server, using InSim connection? No such framework is implemented now and I do not see an easy and obvious way to implement one.
I do not see why anyone would respond angrily at an attempt to open a discussion about demo. You think there's nothing to discuss, everything is perfect, healthy, with many years ahead? Wow, you're an optimist then. It could be so, but I do not believe it.
I personally care a lot about demo. I believe it is the core of LFS. Without healthy demo scene there'll be no new blood on licensed servers, and everyone would probably agree new blood is needed there, a lot. Thinking about demo should be a priority then, not some sideway matter.
Two and a half years ago there was a major change in demo. Reversed BL tracks were removed and unavailable to demo people. From my perspective, the effects of this action were purely negative. A large community, especially around BL2R was simply killed. A few bought S2, but most simply left LFS. It was a major blow and nobody will convince me it was not so. Since that day I see decline in LFS.
Except for one or two more smaller patches things did not move anywhere for two years now. In the past months, several times I was proposing to developers some changes to be made. Changes that would take from 5 minutes to one day max (estimate) to incorporate. Changes that could improve demo, breath new life there. There was no response.
My ideas for improvements:
1) Open again BL1R and BL2R for demo people. Closing down the tracks was bad for LFS, in my eyes, opening them again should have opposite effect.
2) Maybe limit demo usage by time, say to 3 or 6 months. When the time expires, gathered stats are completely erased and the demo username blocked, probably indefinitely. Sure, people can get new name, but at least stats on LFSW would be under control, which should make Victor happy.
3) If point 2 would be accepted, it would be cool to have an option to get real S0 licence. Unlimited demo usage, without time restriction, for something like 3 pounds. Many people would be willing to give this much. And many admins would be willing to organize demo series with S0 licences to the winners, simply because they're cheap. (Because how many demo competitions a year you can run if promising S2 licence to the winner?)
From my perspective, the above changes could have substantial positive impact and I do not think they involve extreme amount of work. Scawen needs only to open the tracks again. Victor would have a tougher job, but I believe it is mostly database manipulation and it could be workable.
Of course I may be wrong, both in assuming it would be good for LFS and in assuming it is not too much work for developers. But how could I or anyone else know if we do not try and if developers do not respond? My apologies to anyone who feels enraged by such proposals, but I see them as beneficial.
I personally care a lot about demo. I believe it is the core of LFS. Without healthy demo scene there'll be no new blood on licensed servers, and everyone would probably agree new blood is needed there, a lot. Thinking about demo should be a priority then, not some sideway matter.
Two and a half years ago there was a major change in demo. Reversed BL tracks were removed and unavailable to demo people. From my perspective, the effects of this action were purely negative. A large community, especially around BL2R was simply killed. A few bought S2, but most simply left LFS. It was a major blow and nobody will convince me it was not so. Since that day I see decline in LFS.
Except for one or two more smaller patches things did not move anywhere for two years now. In the past months, several times I was proposing to developers some changes to be made. Changes that would take from 5 minutes to one day max (estimate) to incorporate. Changes that could improve demo, breath new life there. There was no response.
My ideas for improvements:
1) Open again BL1R and BL2R for demo people. Closing down the tracks was bad for LFS, in my eyes, opening them again should have opposite effect.
2) Maybe limit demo usage by time, say to 3 or 6 months. When the time expires, gathered stats are completely erased and the demo username blocked, probably indefinitely. Sure, people can get new name, but at least stats on LFSW would be under control, which should make Victor happy.
3) If point 2 would be accepted, it would be cool to have an option to get real S0 licence. Unlimited demo usage, without time restriction, for something like 3 pounds. Many people would be willing to give this much. And many admins would be willing to organize demo series with S0 licences to the winners, simply because they're cheap. (Because how many demo competitions a year you can run if promising S2 licence to the winner?)
From my perspective, the above changes could have substantial positive impact and I do not think they involve extreme amount of work. Scawen needs only to open the tracks again. Victor would have a tougher job, but I believe it is mostly database manipulation and it could be workable.
Of course I may be wrong, both in assuming it would be good for LFS and in assuming it is not too much work for developers. But how could I or anyone else know if we do not try and if developers do not respond? My apologies to anyone who feels enraged by such proposals, but I see them as beneficial.
Hmm, understood. Actually, I think the TS support in Relax does not work anymore? I did some preliminary research and it seems there's a nice TS library that could be used. Unfortunately all my experiments failed so far in connecting to TS server. I posted a question into one of TS forums, we'll see if these initial troubles can be solved, somehow...
Wow, that is a very old stuff there. If I understand correctly, it is for TS2 version. I searched around a bit and there are some .NET libraries for TS3 available, so maybe they could be used. Somehow. Uhm. What would you need, what would be desirable? I do not use TS myself, so my notion about what it does and how it works are a bit hazy. Rather quite hazy. 
You need to see that now it is a basic framework - graphical selection, showing number of votes, choosing site and then track based on user left-clicks (to give vote, multiple options allowed, but only one vote for each from one connection) and right-click (to cancel an earlier given vote). I believe it works as it is supposed to, which is important. But people already express some doubts or reservations, mention possible abuses.
And the objections may be correct. But I think we may wait a bit, see if the undesirable actions happen in reality. By this I mean a bunch of people always voting for one track, majority voting to end race right after rotation to call new voting, generally moving just between two or three tracks.
When 2.4.9 is released (soon) and used for a time, we'll know more. I already have some relatively simple mechanisms in mind that could be used to fight the possible negative sides of voting. For example: 1) Prohibit race end voting for at least one race start on newly selected track, or better for a set time. 2) Keep rotation stats and prefer not much used tracks.
This could be done by e.g. assigning them negative number of votes from the start. Say we go from AS3. AS as a site will be given e.g. -2 votes, while other sites will start with 0. Same for AS3, if AS is actually selected. And the negative numbers may rise in time. Or other sites/tracks may be given positive votes (e.g. +2 votes for the track that is actually already loaded, next in defined rotation).
The options are there, but I think time will show if it really is necessary. Admins should also know they can cancel the vote just like any other, using !cv. We'll see, but I have to say when there were about 20 people on the & Genuine GT Racing server, which is currently used for testing, it was great fun to see how the votes were raising and how people voted in the last second to switch to some other track.
Indeed I did, a week ago or so. But in fact version 2.4.9 is almost ready. And it brings one feature that was requested for some time and that I personally like a lot! Be sure to read the Airio changelog, that I was finally able to complete.
No idea.
Just a question though: Does it concern display of good splits? When yours are shown but other people's are not? If so, it is not a glitch in fact and I'll explain in more detail here.Nice one!
Using speed in Airio is tricky, because data reported by server are constant for substantial periods (one second or even more), and then there's a sudden jump. Because of this delay, speed checks are not quite reliable for braking (as was the intention), but they can be safely used for accelerating, so what you gave us is a very good application of an existing feature. Thanks!Well, I guess there will come a day when both are included. BabyOnWheels already has a code to do the GP stuff, and it is available, maybe I could look for inspiration there. For the rolling start I'd still need to gather all the requirements, especially in weird conditions (e.g. someone lagging/timing out) and convert them into some applicable structure. But certainly this would be a great addition.
Now I think I should put this as a quotation into my signature.
Talking about me, the bug. Well, many (or at least some) would agree. 
Pity my signature space is spent already. But I get now what you meant. 
Hm, I believe talking to host works, it redirects output to an IRC channel, and so should !admin work. Certainly it should display something - if the hidden message was forwarded or not. I'll check, one day...
By default limads level 2 can only ban online people and only for 12 hours. That's why the Ban button is not shown for them in !rn list, these people are not online anymore.
OMG. Well, theoretically, using an intricate solution, it could be possible, I think. The problem is gears are not available using the standard TCP packets, they are only available as OutGauge data, using UDP communication and only for the currently viewed car. To implement the check, server would need to request OutGauge data and cycle through all cars constantly (I'm not sure now how this could be done). Uhm...
Well, before some kind of acceleration check is available, I'd suggest using MaxSpeedNodes in TCD file. The default ones are for braking zones, and as already mentioned I have some doubts about real usability.
However, creating MaxSpeedNodes at acceleration places should be possible and in fact very effective. For a start, I'd suggest adding the following item to the TCD file, under BL1 and XFG plus XRG plus FBM:
MaxSpeedNodes=0,0|74-80 + 0,0|170-174 + 0,0|208-212 + 0,0|250-254 + 0,0|292-296
The zeroes mean there will be only speed measuring going on, both in 1st and subsequent laps, this all in every major acceleration zone, after chicanes and main turns.
For the speed check to run you need to have CheckMaximumSpeed set to true in SRV file. This check is available only in Airio FULL and PROS version. Also advanced check must be turned on, as shown by !chk.
Entry speed into the zones is measured, so you may move them a bit, maybe. While the zeroes are in effect, the measured speed is stored into log file as a DEBUG message, which means LogDebugs must be active. (I'm not sure now, maybe using !deb admin command also turns the debug logging.)
From logs then maximum speeds could be read and zeroes replaced by kmph data. one catch though... This check runs only during race, because of its primary intention, to prevent crashes. Eh, should be optional...
However, creating MaxSpeedNodes at acceleration places should be possible and in fact very effective. For a start, I'd suggest adding the following item to the TCD file, under BL1 and XFG plus XRG plus FBM:
MaxSpeedNodes=0,0|74-80 + 0,0|170-174 + 0,0|208-212 + 0,0|250-254 + 0,0|292-296
The zeroes mean there will be only speed measuring going on, both in 1st and subsequent laps, this all in every major acceleration zone, after chicanes and main turns.
For the speed check to run you need to have CheckMaximumSpeed set to true in SRV file. This check is available only in Airio FULL and PROS version. Also advanced check must be turned on, as shown by !chk.
Entry speed into the zones is measured, so you may move them a bit, maybe. While the zeroes are in effect, the measured speed is stored into log file as a DEBUG message, which means LogDebugs must be active. (I'm not sure now, maybe using !deb admin command also turns the debug logging.)
From logs then maximum speeds could be read and zeroes replaced by kmph data. one catch though... This check runs only during race, because of its primary intention, to prevent crashes. Eh, should be optional...
I'm afraid I have nothing special available above the defaults. A word of caution concerning the speed: LFS server updates the speed values at best just twice a second or even with longer intervals. And a second is great speed difference when braking hard. Thus defining and activating braking zones is dangerous - people may get spectated because of lags and not because of crashing.
On the other hand speed check in acceleration zones would work well. If someone is seen moving at 200 kmph where regular cars move 150 kmph at best, something is very wrong and spectate for security would be great. The speed hackers actually use sort of limiters that would make them slower at max speed, but still accelerate impossibly.
The acceleration check could be an implementable idea, with max acceleration allowed per car. But impossible accelerations happen quite often during crashes. Unfortunately if acceleration check is available and applied, all such cases would be addressed, resulting in spectate for security...
On the other hand speed check in acceleration zones would work well. If someone is seen moving at 200 kmph where regular cars move 150 kmph at best, something is very wrong and spectate for security would be great. The speed hackers actually use sort of limiters that would make them slower at max speed, but still accelerate impossibly.
The acceleration check could be an implementable idea, with max acceleration allowed per car. But impossible accelerations happen quite often during crashes. Unfortunately if acceleration check is available and applied, all such cases would be addressed, resulting in spectate for security...
The on/off path check is done completely right on the server (in AIRIO), only results are sent to airio.eu (to AUTIO). If you do not see the on/off path messages, you may have Path check messages turned off in !opt, or Airio does not have the necessary path files available. Also Airio PROS is required for AIRW data. At present there are no problems, and all data are processed correctly.
Actually, there was one more condition added today, that may have influence in certain cases. Updates of people with LFS Experience Index below 100 are ignored. This is done to protect demo good laps from speed hacks and data loss (as it happened twice already). The requirement has additional implication: People with hidden LFSW stats have 0 experience and are from today ignored by AIRW.
To be recognized, LFSW stats must be made available. I have already contacted people that have many LFSW records stored, but they hide their LFSW data. In several days all such records will be deleted (several dozens), only people with known experience will be considered by AIRW.
Actually, there was one more condition added today, that may have influence in certain cases. Updates of people with LFS Experience Index below 100 are ignored. This is done to protect demo good laps from speed hacks and data loss (as it happened twice already). The requirement has additional implication: People with hidden LFSW stats have 0 experience and are from today ignored by AIRW.
To be recognized, LFSW stats must be made available. I have already contacted people that have many LFSW records stored, but they hide their LFSW data. In several days all such records will be deleted (several dozens), only people with known experience will be considered by AIRW.
Airio 2.4.8
New Airio version is available (see my signature below). It corrects known problems and improves several existing features. There are more textual parameters available to be used in custom messages/buttons, such as {CurrRateValue} or {CurrRateText} in FULL/PROS version. New is also the !cat command showing categories and cars of people currently on track, with total numbers. I'm not able to properly update the changelog now, hopefully my notebook will be repaired next week and all new things will appear there.
If server log capturing is active (only in FULL/PROS version, using LogServer and LFSPath in SRV file), most IP addresses are captured, assigned to just connected people and used for initial language assignment, and also for temporary IP blocking after a ban. The address is not stored in Airio stats, it is only in Airio log file. Also the IP block is only temporary (15 minutes by default), because many many IP addresses are shared and blocking them for longer periods have negative impacts. But the length of blocking is configurable using IPBanLength in CFG file.
If server log capturing is active (only in FULL/PROS version, using LogServer and LFSPath in SRV file), most IP addresses are captured, assigned to just connected people and used for initial language assignment, and also for temporary IP blocking after a ban. The address is not stored in Airio stats, it is only in Airio log file. Also the IP block is only temporary (15 minutes by default), because many many IP addresses are shared and blocking them for longer periods have negative impacts. But the length of blocking is configurable using IPBanLength in CFG file.
LOL, contrary to what seems the be the widespread and popular belief, I could understand the post very well.
But in fact I do not care about rhama, I do not know that guy from AA servers (but will check to be sure). The fact is that I have a replay here where Inny drives real magic car (I double checked to be sure right now). Also it is a hacked FBM with speed limited to 230 kmph (above which AA Airio always spectates for security). So it was an attempt at limiting the cheat and hiding it, double cheat then. I'll try to come up with some solution, a list of number of people currently on track in available car categories.
I can't help to comment on this: All stats of Inny (author of the post/report) were erased from AA servers and the username permanently banned for trying to cheat (and failing miserably). But that is just AA no tolerance policy.
Hm, good ideas, I think. The problem is that banning code inside Airio is quite complicated (because of the custom banning system), so it would require careful placement of any communication about bans. Well, in fact I could maybe limit it to the custom banning system only (the one which lets people connect, but kicks them straight away with info about remaining ban length and optionally also the ban reason).
Jason and Boothy came with some global Airio racing data statistics and possible use, which sounds interesting, though it will require quite a few updates both in Airio and in the AIRW Web scripts/pages. So I guess the banning info could be included there somewhere and communicated back to clients when they ask for initial AIRW data after connection.
Well, sorry, but I need to return to one old thing, the UFB (UFR, 45%) and XFJ (XFR, 43%) cars. No doubt they fall into the same category, but what would be the category name? And what names to use for less restricted UFR and XFR? And what category will that be?
I think there's really one clean solution. We could have UFB and XFB, where B stands for "Baby". The category would be GTB (Baby GT). Then there could be UFJ (UFR, e.g. 23%) and XFJ (XFR, e.g. 21%), where J stands for "Junior". The category is logically GTJ.
Then there are the GTR cars, but this is already set as GT2 and GT3 category, no need for changes there. So the only thing is XFJ needs to be locally renamed to XFB, because XFJ may be a different car... Uhm, I hope this makes sense.
I think there's really one clean solution. We could have UFB and XFB, where B stands for "Baby". The category would be GTB (Baby GT). Then there could be UFJ (UFR, e.g. 23%) and XFJ (XFR, e.g. 21%), where J stands for "Junior". The category is logically GTJ.
Then there are the GTR cars, but this is already set as GT2 and GT3 category, no need for changes there. So the only thing is XFJ needs to be locally renamed to XFB, because XFJ may be a different car... Uhm, I hope this makes sense.
Hm, that really is strange. With paid key everything should work smoothly. I just connected to RR and my experience was shown almost immediately, meaning the paid service really works. Also !ex was showing full experience of everyone connected. But then I tried !exr to refresh my rating and I received no response. Hm... No, it is not possible to mix paid and unpaid keys, that would not work. As always log from about the time I'm writing this would (maybe) help...
PS: I'd suggest to erase the used LFSW key, generate new one and use it...
I believe Born2BSlow solved his troubles - I guess the usual confusion about game port set by /port and insim port set by /insim was the cause. But please everyone note the following:
If I recall correctly this is NOT true, it is in fact highly confusing. (Sorry, Anthoop!) Whenever you type /insim on client, it will set your local insim port and NOT server port! The only way to set server insim port is using server console (but you have it available only when running the server locally, on your PC), or by editing LFS server setup.cfg file and restarting the server. But note that at 500servers you may not change server insim port, you must use what you have and adjust Airio accordingly.
If I recall correctly this is NOT true, it is in fact highly confusing. (Sorry, Anthoop!
) Whenever you type /insim on client, it will set your local insim port and NOT server port! The only way to set server insim port is using server console (but you have it available only when running the server locally, on your PC), or by editing LFS server setup.cfg file and restarting the server. But note that at 500servers you may not change server insim port, you must use what you have and adjust Airio accordingly. Nope, I was too lazy to create a separate queue for AIRW requests, and also afraid a bit of too many requests coming at the same time, so I put it into the existing LFSW queue. Also the 5 seconds between requests is minimum amount and unsafe, so 6 seconds delay is used internally. PS: Each added LFSW key halves the delay...
Last edited by EQ Worry, .
I believe Dave is correct. To get the LFSEI, at least download of personal records and personal online stats from LFSW is required. But these requests are accompanied by other, such as LFSW hotlaps, and AIRW records plus hotlaps. This in fact makes 5 requests:
10.07.30 12:39:15 #1 C01P00 åir - Requiring LFSW OS data...
10.07.30 12:39:15 #1 C01P00 åir - Requiring AIRW VB data...
10.07.30 12:39:15 #1 C01P00 åir - Requiring AIRW VL data...
10.07.30 12:39:15 #1 C01P00 åir - Requiring LFSW HL data...
10.07.30 12:39:15 #1 C01P00 åir - Requiring LFSW PB data...
If just one unpaid LFSW key is used, then getting all the data will take almost 30 seconds, and even (much) more if there are other requests already queued!
There are two solutions to speed up requests. One is to use paid service. Put some money on your LFS account and specify in Airio CFG file that the service is paid for. My estimate is that on RR the monthly cost will be between 0.5 and 1 pound. I did a test, and month paid requests cost 3.5 pounds on AA demo servers, but they are rather a busy lot.
The other solution applicable for FULL and PROS versions is using multiple LFSW keys, which you may get e.g. from your teammates. Note that each much generate only one key and that key must not be used anywhere else, or requests may fail. (From this perspective generating multiple keys under one account is the worst you can do.) If you can use e.g. 5 additional keys, then all the requests will be done in 5 seconds, which is rather reasonable time. (With paid service the time is usually under 1 second.)
10.07.30 12:39:15 #1 C01P00 åir - Requiring LFSW OS data...
10.07.30 12:39:15 #1 C01P00 åir - Requiring AIRW VB data...
10.07.30 12:39:15 #1 C01P00 åir - Requiring AIRW VL data...
10.07.30 12:39:15 #1 C01P00 åir - Requiring LFSW HL data...
10.07.30 12:39:15 #1 C01P00 åir - Requiring LFSW PB data...
If just one unpaid LFSW key is used, then getting all the data will take almost 30 seconds, and even (much) more if there are other requests already queued!
There are two solutions to speed up requests. One is to use paid service. Put some money on your LFS account and specify in Airio CFG file that the service is paid for. My estimate is that on RR the monthly cost will be between 0.5 and 1 pound. I did a test, and month paid requests cost 3.5 pounds on AA demo servers, but they are rather a busy lot.
The other solution applicable for FULL and PROS versions is using multiple LFSW keys, which you may get e.g. from your teammates. Note that each much generate only one key and that key must not be used anywhere else, or requests may fail. (From this perspective generating multiple keys under one account is the worst you can do.) If you can use e.g. 5 additional keys, then all the requests will be done in 5 seconds, which is rather reasonable time. (With paid service the time is usually under 1 second.)
Ah, right, I guess it is from the initial post in this thread. Well, better to use the 1st link in my signature, the pages were turned into ASPX. The (much) worse thing is the user/admin/full documentation is very very obsolete. It contains just about third of the actual options and some info is straight misleading and not applicable anymore. There's been so many changes between 2.0 and current version (almost 2.5)... One day I must look seriously into the document and correct at least the info that is wrong... But, eh... What is always up to date is local help system called by !help, the available configuration files (CFG, TCD, SRV), and the changelog. These together represent the best info...
Thx!
Last edited by EQ Worry, .
Well, probably my mind is dimmed this late in the evening, but how could I ask client what time zone he is in? People do not connect to Airio, only to LFS server, and the server, if I'm not mistaken, does not readily give any info about where the users come from.
The only solution I see now is to use county info found in LFSW online stats (which Airio already downloads and uses), and deduce (if possible, I'm not sure), what time in the specified country is. But then there are large countries with several time zones. Uhm...
Ah, I got it now, sry.
Hm, buttons are tricky, there's so many of them that I would first need to optimize the usage, which is a very lengthy process prone to errors. So if it is possible to show the correct time in the end, I'll stick to chat for a start. But...No problem, I'm always happy when troubles sort of get solved by themselves.
FGED GREDG RDFGDR GSFDG